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(57) Abstract: The invention relates to a method, a system, 
telecommunication servers and a network node for storing 
sensitive information such that they are easily retrievable 
when needed for instance using an identity number without 
extra identifiers, but stored such that they cannot be associated 
with an individual. The invention is based on the use of 
an internal identifier and two separate databases such that 
upon reception of a storage request (700) including data to 
be stored and the first identifier for identifying the individual 
with whom the data to be stored is associated, then a second 
identifier is generated such that its value does not depend on 
the first identifier; the first identifier and the second identifier 
are stored in the first database by binding the first identifier 
to the second identifier; and the data to be stored is stored in 
the second database together with the second identifier- 
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Storing sensitive information 

FIELD OF THE INVENTION 

[0001] The invention relates to storing sensitive information con- 
cerning an individual and particularly to storing a patient's prescription and/or 
5 other patient data. 

BACKGROUND OF THE INVENTION 

{0002] Conventionally, prescription data are only stored in an actual 
paper prescription or -possibly in databases of a closed data system used by 
- the physician. Similarly, patient data are maintained stored on paper in what 

10 are known sis patient records and in addition possibly in a closed data system 
of a clinic, health centre and/or hospital. Outside organizations have no access 
to these data. As telecommunication connections have improved, for instance 
various prescription transfer systems have been developed, most of which are 
based on the direct transmission of a prescription to the pharmacy delivering 

15 the drug, and thus no database of the prescriptions has been accumulated. 
However, the problem in such solutions is that when writing the prescription, 
the person has to decide the pharmacy to be used. 

[0003] As a solution to this problem, a centralized database has 
been proposed, wherein the prescriptions are stored and from where they can 

20 be retrieved in any pharmacy. However, the problem in such a database is that 
the confidentiality of the data has to be guaranteed, i.e. the fact that outsiders 
have no way to find out what prescriptions were written for a given individual. 

[0004] A manner of solving this problem is that the prescription data 
are stored together with an external identifier relating to the individual, which 

25 identifier does, however, not enable the identification of the individual, and ac- 
cess to the data is only by said external identifier. The external identifier may 
be for instance a biometric identifier, such as a fingerprint, or a code in a per- 
sonal smart card. However, the use of an external identifier is subject to code 
readers both at the storing end and the data retrieval end, and even to the in- 

30 dividual carrying along the code in a separate card or the like. 

[0005] Another manner is to secure the data by strong encryption. 
The problem in strong encryption is that is ages with time and thus becomes 
unprotected. Prescription and patient data should remain secret for several 
dozens of years. Encryption is also subject to the use of encryption programs 

35 during data storage and the use of a decryption program during data disas- 
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sembly. These programs are different for different encryption methods. An- 
other drawback in the methods is that an agreement has to be made regarding 
how the encryption keys are used, stored and changed. In addition, the use of 
strongly encrypted data for research and other corresponding use is very diffi- 
5 cult, and when public key encryption is used, in practice impossible. 

BRIEF DESCRIPTION OF THE INVENTION 

[0006] The object of the invention is thus to provide a method and 
an apparatus for implementing the method so as to allow the retrieval of sensi- 
tive information by individuals using a generally used individual identifier, such 
10 as an identity number, but the sensitive information being stored in such a 
manner that they cannot be associated with any individual. The object of the 
invention is achieved by a method, telecommunication servers, network node 
and system, which are characterized in what is stated in the independent 
claims. Preferred embodiments of the invention are described in the dependent 
5 claims. 

[0007] The invention is based on separating sensitive information, 
such as a drug prescription included in a prescription, and the individual's iden- 
tity data, such as the identity number, from each other at the storage stage by 
storing the individual's identity data in a first database and the sensitive infor- 

20 mation in a second database such that the information are bound together by 
means of a second identifier. The second identifier does not as such include 
anything that would associate it with a given individual. In this way, sensitive 
information is retrievable by means of the individual's identifier data, and can 
be studied at the same time without the individual's identifier data. Herein, a 

25 drug prescription preferably includes all medication data in the prescription. In 
other words, the invention is based on the use of two separate databases by 
means of an internal identifier. 

[0008] An advantage of the invention is that sensitive information 
does not have to be encrypted, since the second database including sensitive 

30 information does not include anything that would reveal to anyone studying the 
information, either permissibly or without authorization, the individual with 
whom the sensitive information is associated. In addition, the sensitive infor- 
mation is in the use of researchers and authorities without any risk to any- 
body's privacy and/or without the need to give any secret information to re- 

35 searchers or authorities that would enable the disassembly of the information 
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into a usable form. A further advantage is that during storage or retrieval of 
information associated with a given individual, the user of the system does not 
have to have separate reading devices or the like, nor does the individual have 
to carry along or purchase an identification unit including extra information, 
5 such as a smart card. A still further advantage is that since the identifier used 
in data retrieval is an identifier internal to the system, the end users of the sys- 
tem do riot have to attend to the operation of the data security system 

BRIEF DESCRIPTION OF THE FIGURES 

[0009] In the following, preferred embodiments of the invention will 
10 be described in detail with reference to the accompanying drawings, in which 

Figure 1 shows an exemplary embodiment of a simplified system 
architecture; 

Figure 2 shows a block diagram of a network node comprising an 
identifier database according to the exemplary embodiment; 
15 Figure 3 shows a block diagram of a network node comprising a da- 

tabase including sensitive information according to the exemplary embodiment; 

Figure 4 shows a block diagram of a telecommunication server ac- 
cording to the exemplary embodiment; 

Figure 5 is a flow diagram of the operation of a network node com- 
20 prising an identifier database according to the exemplary embodiment; 

Figure 6 is a flow diagram illustrating the operation of a network 
node comprising a database including sensitive information according to the 
exemplary embodiment; and 

Figure 7 is a flow diagram illustrating the operation of a telecommu- 
25 nication server according to the exemplary embodiment. 

DETAILED DESCRIPTION OF THE INVENTION 

[0010] In the following, the invention will be described by using as 
an example the transfer of a prescription via a prescription database from the 
place where the prescription is written, such as a health centre or a private 

30 clinic, to a pharmacy. However, the invention is not restricted to this particular 
solution, but the present invention is applicable to the storage of any sensitive 
information, such as patient history, medication history, etc. and its transfer 
wherever required. Another example of applying the invention is the generation 
of a common patient history from both the information of a health centre and 

35 the information of a private clinic, and the use of the common patient history at 
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either the health centre or the private clinic. The invention is also applicable for 
instance to storing billing and/or purchase information in Internet commerce. 

[0011] Figure 1 shows a simplified system architecture showing only 
the elements required for describing the exemplary embodiment of the inven- 
5 tion. The network nodes shown in Figure 1 are logical units whose implemen- 
tation may differ from what is described. It is apparent to a person skilled in the 
art that the system may also comprise other functions and structures that need 
not be described in detail herein. 

[Q01 2] The system comprises a health centre system 1 , a pharmacy 
10 system 2, and two network nodesi 3, 4, both comprising databases and two 
telecommunication networks 5, 5\ via which the network nodes 3^4 are con- 
nected to the health centre system 1 and the pharmacy system 2. In the sys- 
tem, wireless data transfer, data transfer based on a fixed connection, or both 
can be used. 

15 [0013] In the exemplary embodiment of Figure 1, the health centre 

system 1 comprises at least a prescription storage partition 1 1 and a telecom- 
munication server 12. The prescription storage partition 11 refers to means 
and a user interface Ul, which enable the generation and transfer of a prescrip- 
tion via the telecommunication server 12 to the database including the pre- 

20 scriptions. The telecommunication server according to the exemplary embodi- 
ment is described in detail in association with Figures 4 and 7. 

[0014] In the exemplary embodiment of Figure 1 , the pharmacy sys- 
tem 2 comprises a telecommunication server 22, by means of which the pre- 
scription is retrieved from the database including the prescriptions and via 

25 which any notes to be made in the prescription can be stored, and a prescrip- 
tion processing partition 21 arranged to display the contents of the prescription 
via a user interface Ul' to the personnel at the pharmacy, and via which the 
personnel is able to for instance store information associated with the delivery 
of the prescription. In the exemplary embodiment, the telecommunication 

30 server 22 in the pharmacy system is similar to the telecommunication server 
12 in the health centre system. In some other embodiments of the invention, 
the functions of the telecommunication servers may be different. 

[0015] It is apparent to a person skilled in the art that both the 
health centre system 1 and the pharmacy system 2 comprise other subsys- 

35 terns and/or partitions that are not described in detail herein, since they are 
irrelevant to the actual invention. Examples of these include different identifica- 
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tion systems and firewalls for ensuring e.g. that only authorized persons are 
able to store/read the information. It is also apparent to a person skilled in the 
art that there may be several health centre and pharmacy systems and/or ele- 
ments comprised thereby. 
5 [0016] The exemplary embodiment of Figure 1 comprises two sepa- 

rate network nodes 3, 4, both of which comprise a database DB1, DB2. The 
databases differ from each other in such a manner that sensitive information is 
stored in one database, i.e. drug prescriptions in the exemplary embodiment of 
invention, and data identifying an individual in the other. The structure of the 

10 databases will be described in detail in association with Figures 2 and 3, and 
their operation in the exemplary embodiment in association with Figures 5 and 
6. In sorne other embodiment of the invention, the databases may be physi- 
cally located in the same network node, being, however, separate databases. 
The databases or one of them may comprise several interlinked databases 

1 5 that may be located even physically in different network nodes, which network 
nodes may be part of a closed or open data network. The interlinked data- 
bases may also include different data. For example, an open database may 
include interlinked databases such that one linked database comprises drug 
prescription data, the second laboratory data and the third age, length and 

20 weight data. For an end user, these interlinked databases behave as one inte- 
gral database. 

[0017] Both network nodes including a database are connected to 
the telecommunication servers 12, 22 via the telecommunication networks 5, 
5'. The telecommunication system on which the intermediate networks are 

25 based and whether they are based on the same or different systems is irrele- 
vant to the invention. The networks may be for instance Internet networks, 
telephone networks or mobile networks. 

[0018] Although the assumption in the exemplary embodiment of 
the invention is that the telecommunication server is part of the subsystem to 

30 which it transfers data from the database or from which it transfers data to the 
database, it is apparent to a person skilled in the art that the telecommunica- 
tion server may be arranged as a separate network node or in a node including 
either database. The fact that the telecommunication server is part of the sub- 
system brings about the advantage that sensitive information does not have to 

35 be sent in a common network together with an identity number. This improves 
further the data security of an individual. 
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[0019] Figure 2 illustrates a database including identifiers, a so- 
called identifier database, i.e. a network node 3 according to the exemplary 
embodiment, comprising a connection part 31 , an application part 32, and a 
database DB1 including personal data. 

5 [0020] The database DB1 including personal data comprises re- 

cords 33, wherein an identity number lDNO is connected to an identifier IDEN- 
TIFIER generated for that particular identity number. The identity number is an 
identifier used for unambiguously identifying an individual. The generated idenr 
tifier is preferably unambiguous within the database comprising sensitive data 

0 in such a manner that in the database comprising sensitive data, one value of 
a generated, identifier can be associated with only one individual. One individ- 
ual may have several generated identifiers, but the assumption in the exem- 
plary embodiment is that one individual has only one generated identifier. The 
database may also comprise, e.g. as a listing (not shown in Figure 2), informa- 

5 tion about the telecommunication servers that have access right to the data in 
the database. 

[0021] The connection part 31 receives various requests from both 
the telecommunication server of the pharmacy system and the telecommunica- 
tion server of the health centre system, and transfers responses to the re- 

20 quests. The requests are typically data retrieval requests inquiring about the 
generated identifier associated with a given identity number. The connection 
part 31 may also be arranged to transfer information to the application part 32 
about the telecommunication server from which the request was received. 

[0022] The application part 32 is configured to search the database 

25 for the generated identifier corresponding to the identity number and to return it 
via the connection part 31 to the telecommunication server that inquired about 
it. The application part 32 may also be configured to check from the database, 
before retrieval of the generated identifier, if the telecommunication server in- 
quiring about the data is an authorized telecommunication server, i.e. if it is 

30 found for instance in the list in database DB1, and if the telecommunication 
server is not authorized, to send for instance either mere blank data or a nega- 
tive acknowledgement to the telecommunication server that inquired about the 
data. The application part 32 may also be configured to add new telecommuni- 
cation servers to the list of authorized telecommunication servers in the data- 

35 base. In the exemplary embodiment of the invention, the application part 32 is 
configured to send a negative acknowledgement to the telecommunication 
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server inquiring about a generated identifier if the generated identifier is not 
found, and, in response to a generation request received from the telecommu- 
nication server, to generate the identifier, store it together with the identity 
number as a record 33 in database DB1, and to send the identifier thus gener- 

5 ated via the connection part 31 to the telecommunication server that sent the 
generation request. The generated identifier, may be e.g. a running number. 
' However, the invention does in no way restrict the form and/or contents of the 
generated identifier. In some other embodiments of the invention, wherein for 
instance the telecommunication server or some other party attends.to the gen- 

10 eration of the. generated identifier, the application part 32 is configured to for 
instance send mere blank data or a negative acknowledgement to the tele- 
* communication server that inquired about the generated identifier when the 
generated identifier was not found . In still another embodiment of the invention, 
the application part may be configured to generate the generated identifier in 

15 response to no generated identifier being found for the identity number, to 
store it together with the identity number as a record in database DB1 , and to 
send the thus generated identifier via the connection part 31 to the telecom- 
munication server that inquired about it. 

[0023] Since in the exemplary embodiment only the identifier data- 

20 base is able to associate a given generated identifier with a given individual, 
sensitive data remain secret in the second database thus guaranteeing the 
individual's data security. 

[0024] In another embodiment of the invention, the identifier data- 
base may include not only the identity number, but also some less identifying 

25 data, such as for instance an address or other demographic data. 

[0025] In another embodiment of the invention, the identifier data- 
base may also include data associated with consent management. In such an 
embodiment, for instance the consent of a patient is asked to storing his drug 
prescription(s) in a database and/or to what kind of data can be stored in the 

30 database. 

[0026] In another embodiment of the invention, the identifier data- 
base may also comprise su ^identifiers that can be used to determine the right 
of one possessing a subidentifier to process the data in the database including 
sensitive data. An example of a subidentifier is the identifier of an advertiser. 
35 The ads of the advertiser can be sent to the owners of the identifiers to which 
the advertiser's identifier is attached. 
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[0027] In other embodiments of the invention, the application part 
32 is configured to carry out functions associated with the embodiments. 

[0028] Figure 3 illustrates a database including sensitive data, i.e. a 
network node 4 according to the exemplary embodiment, comprising a connec- 
5 tion part 41 , an application part 42 and a prescription database DB2. 

[0029] The connection part 41 receives various requests from both 
the telecommunication server of the pharmacy system and the telecommunica- 
tion server of the heajth centre system, and transfers responses or acknowl- 
edgements to the requests. The requests are.typically data retrieval requests, 
10 data storage requests or data edit requests. The connection part 41. may also 
be arranged to transfer information to the application part 42 about the tele- 
communication servej from which the request was received. . - 

[0030] The database DB2 comprising prescriptions includes records 
43, wherein all drug prescriptions and any other data associated with the iden- 
15 tifier are connected to a generated identifier IDENTIFIER in the exemplary em- 
bodiment. In other words, upon storage of data, the record is searched for, 
which includes the corresponding identifier and the data are stored therein in 
addition to the data already there. In another embodiment of the invention, the 
data are stored in smaller records including an identifier and the data stored at 
20 that particular time. In this embodiment, when data are retrieved, all records 
including said identifier are retrieved from the database. At its simplest, the 
database comprising prescriptions only includes open prescriptions, i.e. pre- 
scriptions not yet delivered or those of which only part is delivered. The data- 
base comprising prescriptions may also include e.g. medication history, patient 
25 history, various background data of the patient, such as age, weight, smoking, 
etc., information of adverse effects of the medication, results of laboratory tests 
and/or information about allergies. The database may also include, for instance 
as a listing (not shown in Figure 3), information about the telecommunication 
servers that have access right to the data in the database. The telecommuni- 
30 cation servers may also be listed such that some have the right to obtain only 
data associated with the requested identifier, some have the right only to re- 
quests not including an identifier (i.e. mass information), and some telecom- 
munication servers have access right to all data. The database may also com- 
prise subidentifiers usable for instance for determining the rights one possess- 
35 ing a subidentifier has to process the data in the database. 

[0031] The application part 42 is configured to distinguish the differ- 
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ent requests from each other and to act according to them. The application 
part 42 is thus configured to search the database for the prescriptions corre- 
sponding to the generated identifier and to return them via the connection part 
41 to the telecommunication server that requested them, to store new prescrip- 

5 tions in association with a generated identifier and to edit the prescriptions in 
the database. The application part 42 may also be configured to check before 
retrieval, edit and/dr storage of open prescriptions whether the telecommunica- 
tion server requesting the information is an authorized telecommunication 
server, i.e. if it is found for instance in database DB2 in a list of those author- 

10 ized to receive such information, and if the telecommunication server is not 
authorized , to either send mere blank data or a negative acknowledgement to 
the telecommunication server that made the request. The application part 42 
may also be configured to add new telecommunication servers mine database 
in the list of authorized telecommunication servers. The application part 42 

15 may also be configured to generate and/or store subidentifiers. In the exem- 
plary embodiment of the invention, the application part 42 is further configured 
to carry out various database searches. Database searches may be used for 
instance to find out how many prescriptions (drug prescriptions) were pre- 
scribed last month in the entire country or in Helsinki, which was the most fre- 

20 quently prescribed drug combination for the treatment of rheumatism during 
the last 10 years, how many prescriptions were prescribed for patient A during 
the last 3 years or "The percentage of prescriptions prescribed last year includ- 
ing drug X. The application part 42 may also be arranged to generate subiden- 
tifiers. 

25 [0032] Figure 4 shows a block diagram of a telecommunication 

server 12 according to the exemplary embodiment of the invention. The tele- 
communication server may be an individual, separate server or then for exam- 
ple a software module to be linked to the system. The assumption in the ex- 
emplary embodiment of the invention is that only one type of telecommunica- 

30 tion servers are used in the system, which are added to each subsystem using 
the databases according to the invention. In other words, in the exemplary em- 
bodiment, the same type of telecommunication server is added to all subsys- 
tems retrieving data and/or storing data in a database. In some other embodi- 
ments of the invention, telecommunication servers may be tailored to execute 

35 only the functions required in the subsystem, such as for instance mass data 
retrievals directly from the database of Figure 3 without any identifiers. 
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[0033] The assumption in the exemplary embodiment is that the 
subsystem, as whose part the telecommunication server operates, authenti- 
cates the users and the telecommunication instructions in such a way that the 
telecommunication server is able to trust that only authorized individu- 
5 ais/devices are able to use it. In some other embodiments of the invention, a 
telecommunication server may include various user and/or device authentica- 
tion functions and/or devices for data security reasons. 

[0034] With reference to Figure 4, the telecommunication server 12 
according to the exemplary embodiment comprises two separate connection 

10 parts 121, 121 \ and an Application part 122 between them. 

[0035] The first connection part 121 is configured to communicate 
with the subsystem whose part the telecommunication server is. It receives 
requests from users and forwards them further to the application part, and re- 
ceives responses to the requests from the application part and transmits them 

1 5 further to the user via a user interface. 

[0036] The second connection part 121' is configured to communi- 
cate with the identifier database and the database including sensitive data, i.e. 
the prescription database. The second connection part sends data retrieval or 
storage requests received from the application part or requests generated 

20 based thereon to network nodes comprising databases, and receives re- 
sponses from them, which it forwards further to the application part. 

[0037] The application part 122 according to the exemplary em- 
bodiment is configured to carry out the functions to be executed in detail in as- 
sociation with Figure 7. In brief, in response to a request including an identity 

25 number, the application part 122 is configured to find out the identifier gener- 
ated for the identity number, and, depending on the request, either to store, 
edit or retrieve sensitive information based on the generated identifier. In a cor- 
responding manner, in response to a request not including an identity number, 
the application part is configured to send the request to the database contain- 

30 ing sensitive information. In addition, the application part 122 according to the 
exemplary embodiment is configured to ask the user if an identifier is to be 
generated for an identity number when it is not found in the database, and if 
the user so wishes, to request that the identifier be generated. In another em- 
bodiment of the invention, in response to a request including an identity num- 

35 ber, the application part may be configured to check the right of the requesting 
party to make the request, and carry out the functions required by the request 



WO 03/093956 




•CT/FI03/00332 



only if the requesting party has the right to make the request. 

[0038] In another embodiment of the invention, the telecommunica- 
tion server may comprise memory, to which a predetermined number of gen- 
erated identifiers or a given identifier space is allocated, from which identifiers 
5 may be generated. In this embodiment, in response to an empty response or a 
negative acknowledgement received from the identifier database, the applica- 
tion part 122 is arranged to generate a generated identifier for the identity 
number, to use it in a request to be sent forward, and send it for storage in the 
identifier database if the request is a data storage request. The predetermined 
1 0 identifiers or the identifier space brings about the advantage that such an iden- 
tifier is not generated, which some other telecommunication may have gener- 
ated for some other identity number. 

[0039] In another embodiment of the invention, the telecommunica- 
tion server may comprise a local identifier database. In this embodiment, the 
15 telecommunication server is configured to first search its database for a gener- 
ated identifier and only if it does not find one, request it from the actual identi- 
fier database. In this embodiment, the telecommunication server is also pref- 
erably configured to synchronize its local identifier database either as often as 
possible (e.g. every hour) or when required (always after the generation of a 
20 new identifier) with the actual identifier database. 

[0040] Figure 5 illustrates by a flow diagram the operation of a net- 
work node comprising an identifier database according to the exemplary em- 
bodiment. The assumption in the exemplary embodiment is that the database 
also contains a listing of the telecommunication servers that have access to 
25 the data in the database. 

[0041] When the network node receives a request, in step 500 it 
checks in step 501 if the request was a retrieval request. If so, it checks in step 
502 if the request contained an identity number idno. If the request contained 
an identity number, the network node checks in step 503 if the request was 
30 received from a telecommunication server having access to the data in the da- 
tabase. In other words, it checks if the telecommunication server is an author- 
ized server. If so, in step 504, the identifier database is searched for a gener- 
ated identifier corresponding to the identity number. If the identifier was found 
in the database (step 505), in step 506 it is sent as a response to the request. 
35 [0042] If no retrieval request (step 501) was concerned, in the ex- 

emplary embodiment of the invention an identifier generation request is con- 
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cerned, as a result of which the identifier is generated in step 507 and it is 
stored in step 508 together with the identity number as a record in the identifier 
database, and sent in step 506 as a response to the request. 

[0043] If the request did not include an identity number (step 502) or 

5 the server was not authorized (step 504) or no identifier was found, (step 505), 
a negative acknowledgement is sent in step 509. 

[0044] Figure 6 illustrates by a flow diagram the operation of a net- 
work node Containing a prescription database, i.e.. sensitive information, ac- 
cording to the exemplary embodiment. The assumption in the exemplary em- 

10 bodiment is that the database also contains a listing of the telecommunication 
servers having access to the data in the database such that there is no sepa- 
rate listing of the telecommunication servers that have the right to retrieve data 
based on the generated identifier and of those that have no such right. The 
assumption in the exemplary embodiment of the invention is that the requests 

15 directed to the data associated with a given individual are separated from 
mass data requests based on the identifier in the request. 

[0045] For the sake of clarity, the assumption in the example of Fig- 
ure 6 is that the requested data are found. It is apparent to a person skilled in 
the art that if the requested data are not found, the request is answered for 

20 instance by sending a negative acknowledgement, which may contain the rea- 
son. 

[0046] With reference to Figure 6, when the network node receives 
a request in step 601 , it checks in step 602 if the request was received from a 
telecommunication server having access to the data in the database. In other 

25 words, it checks if the telecommunication server is an authorized server. If so, 
in step 603, a check is made to see if a request relating to an individual's data 
or a mass data request is concerned. If the request included an identifier, in 
step 604 a check is made to see if the request is a data retrieval request. If so, 
in step 605 the requested data is retrieved, in step 606 the data are attached 

30 to the identifier and a response is sent in step 607 to the telecommunication 
server. 

[0047] If a retrieval request was not concerned (step 604), in step 

608 a check is made to see if a storage request was concerned. If so, in step 

609 the data in the request is stored in the database together with the identifier 
35 and in step 610 a positive acknowledgement is sent to the telecommunication 

server. In the exemplary embodiment, each identifier has one record, in which 
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the data are stored in addition to the data already possibly included therein. 

[0048] If a storage request was not either concerned (step 608), 
then in the exemplary embodiment a stored data edit request is concerned, 
whereby, in step 61 1 , the desired changes are stored in the data indicated by 
5 the identifier and the request together, and a positive acknowledgement is sent 
in step 610 to the telecommunication server. 

[0049] If the request did not include an . identifier (step 603), a re- 
trieval request associated with a larger data mass is concerned, of which ex- 
amples were described above, and in step 612 the requested data mass is 
10 retrieved from the database and in step 607 it is sent as a response to the 
telecommunication server. 

[0050] if an authorized server was not concerned (step 602), a 
negative acknowledgement is sent to the telecommunication server in step 
613. 

15 [0051] Figure 7 illustrates the operation of a telecommunication 

server according to the exemplary embodiment. The assumption in the exem- 
plary embodiment is that only an authorized user is able to set up a connection 
to the telecommunication server. In another embodiment of the invention, the 
telecommunication server may be configured to carry out various authentica- 

20 tion measures. The addresses of the network nodes where the databases to 
be used are located are configured in the identification database according to 
the exemplary embodiment. A further assumption in the exemplary embodi- 
ment is that the identifiers to be generated are generated in a network node 
comprising a database. 

25 [0052] When the telecommunication server receives a user's re- 

quest in step 700, it checks in step 701 if the request included an identity num- 
ber idno. If so, in step 702, the telecommunication server separates the identity 
number from the user's request and, in step 703, sends a retrieval request in- 
cluding the separated identity number to the network node comprising the 

30 identifier database. 

[0053] If a response was received from the network node compris- 
ing the identifier database in step 704, and the response included a generated 
identifier (step 705), the telecommunication server adds it to the user's request 
in step 706 and sends, in step 707, the user's request to the network node 

35 comprising the prescription database. The user's request to be sent includes 
the generated identifier, not the identity number. 
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[0054] In step 708, the telecommunication server receives a re- 
sponse from the network node comprising the prescription database, deletes 
the generated identifier from the received response in step 709, adds the iden- 
tity number to the response in step 710, and sends the response to the user in 

5 step 71 1 . The telecommunication server thus operates irrespectively of the 
contents of the response. At the same time, the telecommunication server de- 
letes from its memory the identity number it stored temporarily therein. In an- 
other preferred embodiment of the invention, the telecommunication may col- 
lect a local identifier database and stores therein, the identity number together 

10 with the associated generated identifier. 

[0055] If the user's request did not include an identity number (step 
701 ), in step 71 2 the telecommunication server sends the user's request to the 
network node comprising the prescription database. Having received a re- 
sponse from it in step 713, in step 714 the telecommunication server sends a 

1 5 response to the user irrespectively of the contents of the response. 

[0056] If the response received from the identifier database did not 
include an identifier (step 705), in step 715 the telecommunication server asks 
the user if he wants an identifier to be generated for the identity number. If the 
user wants (step 716) that an identifier is generated, in step 717 the telecom- 

20 munication server sends a generation request to the network node comprising 
the identifier database, receives a response thereto in step 704, from where 
the process proceeds as described above. 

[0057] If the user did not want (step 716) an identifier to be gener- 
ated, in step 718 the telecommunication server sends an acknowledgement to 

25 the user, stating that the information is received. At the same time, the tele- 
communication server deletes from its memory the identity number temporarily 
stored therein. 

[0058] In another preferred embodiment of the invention, the tele- 
communication server does not store even temporarily the identity number, 

30 and in this embodiment the telecommunication server is configured to request 
an identity number using an identifier generated between steps 709 and 710. 
In this embodiment, the network node comprising the identifier database is 
configured to return the identity number to the telecommunication server in 
response to the reception of the generated identifier. 

35 [0059] The steps described in Figures 5, 6 and 7 are not in an abso- 

lute chronological order and can be executed in an order different from the 
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given one. Other functions, such as user authentication and measures relating 
to consent management, may also be executed between the steps. For exam- 
ple, the telecommunication server or the network node comprising either data- 
base may check if the contacting party has access right to the data, e.g. if the 

5 contacting party is a given health centre, a given physician, an authorized ad- 
vertiser or a pharmacist. Some steps described in the figures, such as check- 
ing if the telecommunication server is authorized, may also be omitted. It is 
also feasible to identify the telecommunication server directly from the request, 
what kind of a request is concerned , whereby there is no need to check if the 

0 request included an identity number or a generated identifier. Similarly, the 
network node comprising the identifier database is able to identify, e.g. from 
the structure of the retrieval request, whether the ^retrieval request is such that 
if no identifier is found, an identifier can be generated for it, whereby the steps 
described in Figure 5 change order, some steps may be omitted and new 

5 steps included. 

[0060] Although the invention is described above on the assumption 
that only one generated identifier is associated with one identity number, it is 
apparent to a person skilled in the art that the invention is also applicable to 
solutions wherein several generated identifiers are associated with an identity 
20 number. Based on the above description, the use of databases in these em- 
bodiments is apparent to a person skilled in the art. 

[0061] It should also be noted that the use of the databases is de- 
scribed above using very simplified examples, and it is apparent to a person 
skilled in the art that very complex database inquiries and data updates can be 
25 implemented in the databases according the invention pursuant to the princi- 
ples of the invention. For example, changing the numbering of the medication 
can be carried out directly as a mass run in the database containing sensitive 
information in all the prescriptions including the drug whose numbering 
changes. 

30 [0062] Although the assumption above is that data transfer and the 

sensitive information to be stored are not encrypted, the invention is not re- 
stricted to such a solution. The sensitive information or part thereof can be 
stored in an encrypted form. Data transfer or part thereof may also be exe- 
cuted in an encrypted form. 

35 [0063] Although the invention is described above on the assumption 

that a patient's personal data are protected, the invention is also applicable to 
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protecting the personal data of the physician writing out the prescription in a 
corresponding manner by generating generated identifiers for the physicians' 
identifiers and by storing them either in a special or in the same identifier data- 
base. 

5 [0064] Although the invention is described above using an identity 

number as the identifier identifying an individual, it is apparent to a person 
skilled in the art that other identifiers identifying an individual with a sufficient 
accuracy can be used alternatively or alongside with the identity number. 

[0065] The system implementing the functionality Of the present in- 

10 vention, its network nodes and system parts comprise not only prior art means 
but also means. for implementing the functions described in detail above. They 
comprise processors and memory that can be utilized in the function's of the 
invention! All processing and other means, modifications and additions re- 
quired to implement the invention can be executed as added or updated soft- 

15 ware routines, processors and/or with different application circuits (ASIC). 

[0066] It is obvious to a person skilled in the art that as technology 
advances, the basic idea of the invention can be implemented in a variety of 
ways. The invention and its embodiments are thus not limited to the above ex- 
amples, but may vary within the claims. 
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CLAIMS 

1. A method of storing sensitive information in a system comprising 
two databases, the method comprising at least the steps of: 

receiving a storage request including the information to be stored 
5 and a first identifier for identifying an individual with whom the information to be 
stored is associated; 

characterized by 

generating (507) a second identifier in such a manner that its value 

does not depend on the first identifier; 
10 storing (508) the first identifier and the second identifier in the first 

database in such a manner that the first identifier is bound to the second identi- 
fier; and 

storing the information to be stored in the second database together 
with the second identifier. 
15 2. A method as claimed in claim 1, characterized by further 

comprising the steps of: 

checking (505), before generating the second identifier, in the first 
database if a second identifier is generated for the first identifier; 

if so, using the second identifier in the first database; and 
20 if not, generating the second identifier. 

3. A method as claimed in claim 1 or 2, characterized by 
further comprising the steps of: 

receiving a retrieval request including the first identifier; 
retrieving the second identifier corresponding to the first identifier 
25 from the first database; and 

retrieving the requested information from the second database using 
the second identifier. 

4. A method as claimed in claim 3, characterized by further 
comprising the step of sending, to the request, a response including the re- 

30 quested information and the first identifier. 

5. A telecommunication server (12, 22) in a data system comprising 
at least two databases and a system for generating information to be stored, 
the telecommunication server comprising 

reception means (121) for receiving a request, the request including 
35 the information to be stored and a first identifier for identifying an individual 
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with whom the information to be stored is associated; 

characterized in that the telecommunication server (12, 22) 
further comprises 

first processing means (122) for determining a second identifier cor- 
5 responding to the first identifier in the first database of the data system, the 
second identifier being generated in such a manner that its value does not de- 
pend on the first identifier; and 

second processing means (122) for storing the information to be 
stored together with the second identifier in the second database of the data 
10 system. 

6. A telecommunication server (12, 22) as claimed in claim 5, 
characterized in that 

the reception means (121) are also arranged to receive a data re- 
trieval request and to separate it from the storage request; and 
15 the second processing means (122) are also arranged to retrieve 

the data stored together with the second identifier from the second database of 
the data system in response to the data retrieval request and to forward the 
retrieved data without the second identifier to the party making the data re- 
trieval request. 

20 7. A telecommunication server (12, 22) in a data system comprising 

at least two databases and a system comprising stored data, the telecommuni- 
cation server comprising 

reception means (121) for receiving a request, the request being 
associated with the stored data and including a first identifier for identifying an 
25 individual with whom the stored data is associated; 

characterized in that the telecommunication server further 

comprises 

first processing means (122) for determining a second identifier cor- 
responding to the first identifier in the first database of the data system, the 
30 second identifier being generated in such a manner that its value does not de- 
pend on the first identifier; and 

second processing means (122) for retrieving the stored data to- 
gether with the second identifier from the second database of the data system. 
8. A network node comprising 
35 a database (DB1 ) for storing data, and 

reception means (31) for receiving a request directed to the data- 
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base and for separating a first identifier in the request, the first identifier identi- 
fying an individual with whom the data to be stored is associated; 

characterized in that the network node further comprises 
generation means (32) for generating a second identifier for the first 
5 identifier in such a manner that the value of the second identifier does not de- 
pend on the first identifier; 

storage means (32) for storing the first identifier and the second 
identifier in the database in such a manner that the first identifier is bound to 
the second identifier; and 
1Q response means (31) for returning the second identifier in response 

to the request 

9. A network node as claimed in claim 8, characterized in 

that 

it further comprises processing means (32) for checking if the data- 
15 base comprises a second identifier for the first identifier, and, if not, to trigger 
the generation means; and 

the generation means (32) are configured to be responsive to the 
processing means. 

10. A data system comprising 

20 at least one telecommunication server (1 2, 22) 

at least two databases (DB1, DB2) 
characterized in that 

the first database (DB1) comprises records wherein a first identifier 
identifying an individual is linked to at least one second identifier, which alone 

25 does not identify the individual and whose value is generated in such a manner 
that it does not depend on the first identifier; 

the second database (DB2) comprises sensitive information stored 
in such a manner that each piece of personal information is bound to the cor- 
responding second identifier; and 

30 the telecommunication server (12, 22) is arranged to determine a 

second identifier corresponding to the first identifier in the database in re- 
sponse to a request including the first identifier, to delete the first identifier from 
the request, to add the second identifier to the request and then to send the 
request to the second database. 
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